Synchronization Mark-up Language (SyncML) is a protocol developed to synchronize personal information and intra-enterprise data between multiple platforms and networks. The SyncML protocol defines a series of operations between the participating entities, and defines a set of message formats for carrying such operations. Based on the SyncML, the Open Mobile Alliance (OMA) develops the DS protocol and the DM protocol.
The DS protocol can synchronize personal information and intra-enterprise data between multiple platforms and networks. The DS protocol is generally applied to data synchronization between a mobile device or application server and a network server, or data synchronization between two Personal Computers (PCs).
The DM protocol is a cost-efficient remote management solution that downloads management instruction data from the network to the client, and lets the client run the management instruction automatically to upgrade, configure and diagnose the software and hardware of the client. The DM also transfers the service information required by the operator and the information about the functions of the client from the client to the server, thus supporting operation of other services.
A similar security authentication mechanism is applied to the DS protocol and the DM protocol to authenticate the server and the client effectively, as shown in FIG. 1:
Step 101: The server sends a Trigger message to the client to trigger a session.
The Trigger message carries: a Digest generated by using a random number of the server (s_nonce), and trigger information (TriggerInfo). The Trigger message may be carried in a short message or another Push message.
The s_nonce is a random number (nonce) generated by the client and available to the server.
Step 102: The client sends a session request to the server.
After receiving the Trigger message, the client uses the stored s_nonce to generate Digest information and authenticate the Trigger message. If the authentication succeeds, the client sends a session request to the server to initiate a session.
The session request carries: a SessionID, and authentication information (Authenticate) of the client. The authentication information is a Digest generated by using the client nonce (c_nonce).
The c_nonce is generated by the server and available to the client.
In this step, a session connection is set up between the client and the server.
Step 103: The server returns a response that carries the authentication result and the authentication request.
According to the authentication information sent by the client, the server authenticates the client, and then returns a response that carries the authentication result and the server authentication request.
More specifically, the response carries: a result of the server authenticating the client, a SessionID, and authentication information of the server (namely, a Digest generated by using the s_nonce).
Step 104: The client returns a message that carries the authentication result to the server.
According to the authentication information sent by the server, the client authenticates the server, and then returns a message that carries the authentication result to the server.
More specifically, this message carries: a result of the client authenticating the server, and other relevant information.
If the server authenticates the client unsuccessfully or the client authenticates the server unsuccessfully, for example, the password is incorrect or the nonce value is incorrect, the server or the client may send a challenge request to the opposite party directly to authenticate again.
If the server knows that the s_nonce used in the Trigger message is incorrect, for example, if the server receives no normal response from the client after sending the Trigger message repeatedly, the server believes that the s_nonce is incorrect, and generates the Digest of the Trigger message by using a default nonce “0x00000000”. After authenticating the Trigger message unsuccessfully according to the Digest generated by using the s_nonce, the client uses the default nonce to generate a Digest and re-authenticate the Trigger message. If the authentication succeeds, the default nonce is used to authenticate the server and the client, and then the s_nonce and the c_nonce are updated. The update process is shown in FIG. 2:
Step 201: The server sends a Trigger message to the client to trigger a session.
After determining that the previous s_nonce is incorrect, the server uses the default nonce to generate a Trigger message and sends the message to the client. The Trigger message carries: Digest generated by using the default nonce, and TriggerInfo.
Step 202: The client authenticates the Trigger message unsuccessfully, and uses the default nonce to re-authenticate.
After receiving the Trigger message, the client uses the stored s_nonce to authenticate the Trigger message. If the authentication fails for certain reasons, the client uses the default nonce to re-authenticate the Trigger message.
If the authentication succeeds, it indicates that the s_nonce previously used by the server is incorrect, and the client sends a session request to the server.
Step 203: The client sends a session request to the server.
After authenticating successfully by using the default nonce, the client sends a session request to the server to initiate a session.
The session request carries: SessionID, and Digest generated by using the default nonce.
Step 204: The server returns a response that carries the authentication result, the authentication request, and the command for updating c_nonce.
The server authenticates the client by using the default nonce, and then returns a response that carries the authentication result and the authentication request to the client.
More specifically, the response carries: a result of the server authenticating the client, a command for updating c_nonce, and a Digest generated by using the default nonce.
Step 205: The client returns a message that carries the authentication result and the command for updating s_nonce to the server.
The client authenticates the server by using the default nonce. After the authentication succeeds, the client updates the c_nonce, and then returns a message that carries the authentication result and the command for updating s_nonce to the server.
Step 206: The server returns an s_nonce update result to the client.
In the process of developing the present invention, the inventor finds at least the following defects in the prior art:
The default nonce is used to authenticate in the case that the s_nonce is incorrect. The default nonce is an open fixed value, and the malicious server can intercept the message that uses the default nonce and send the message repeatedly to attack the server or client.
In the prior art, two nonce values are used in one session: s_nonce and c_nonce, which are generated and updated by the server and the client respectively, thus imposing a heavy management load onto the client and the server.